A computer network is a geographically distributed collection of interconnected subnetworks for transporting data between nodes, such as computers. A local area network (LAN) is an example of such a subnetwork; a plurality of LANs may be further interconnected by an intermediate network node, such as a router or switch, to extend the effective “size” of the computer network and increase the number of communicating nodes. The nodes typically communicate by exchanging discrete frames or packets of data according to predefined protocols. In this context, a protocol consists of a set of rules defining how the nodes interact with each other.
Each node typically comprises a number of basic systems including a processor, a main memory and an input/output (I/O) system. Data is transferred between the main memory, processor and I/O system over a system bus, while data transactions within the I/O system occur over an external bus, such as an I/O bus. Each bus typically consists of either address, data and control lines, with the control lines carrying control signals specifying the direction and type of transfer, or a pair of unidirectional communication lines for passing bus packets containing address, data and control information, such as in the case of a HyperTransport (HPT) bus. For example, the processor (i.e., a source) may issue a read transaction to request the transfer of data from an addressed location on an I/O device (i.e., a target) coupled to the I/O bus and over the system bus to the processor. The processor then processes the retrieved data in accordance with instructions that may have been obtained from main memory. The processor may thereafter issue a write transaction requesting that the results be stored in, e.g., an addressed location in the main memory.
Some buses operate in an “atomic” manner such that the source is granted exclusive access (i.e., control) to the bus until the transaction is complete. However, an atomic bus may potentially waste bus cycles, particularly when waiting for data in response to, e.g., a read request. In a split transaction bus, on the other hand, the source relinquishes control over the bus once the request is sent and an independent response to the request is subsequently returned to the source. Here, the target acquires control of the bus to return the response to the source. The split transaction bus thus essentially enables a transaction to be divided into at least two transfers: the request and the response.
Devices coupled to the split transaction bus typically include common sets of resources (such as buffers or queues) used to store request and response transfers sent over the bus. It is possible that some of the resources may be consumed by these transfers, thereby causing the bus to stall waiting on the resources to no longer be in use (freed). This stall, in turn, may result in a plurality of transferred requests concurrently awaiting responses (i.e., “outstanding”) over the split transaction bus. These resources allow several requests to be concurrently awaiting responses over the split transaction bus. Responses to pending requests are additionally limited by the inherent latency of accessing memory locations over the bus.
When a plurality of requests are outstanding, memory access delays may result in responses arriving “out of order.” That is, the responses may be received in a different order than their corresponding requests. For example, assume a source sends a non-posted request R0 to a first target device over a split transaction bus, e.g. a HPT bus. Subsequently, the source sends a non-posted request R1 over the bus to a second target device. As used herein, a non-posted request is a request requiring a response, such as a request to read data. In the situation where the second target device has a lower memory latency than the first target device (i.e., due to memory access optimizations or a faster memory controller), the response to request R1 is received before the response to request R0. Similarly, other consecutive requests may arrive “out of order” depending on how quickly their respective target devices process the requests.
Often, the order responses are received from a split transaction bus is important for reconstructing a packet of information, e.g. a network data packet. Typically, a sequence of responses is sequentially concatenated to form a discrete packet of data/information. The data packet may be used within a predefined network protocol, such as the TCP/IP protocol. Unordered responses may therefore inhibit proper construction of a received information packet.
Furthermore, the order responses are received from a split transaction bus can be important when the response data is retransmitted over another communication channel. These responses may comprise data that will be retransmitted over a general communication link having predefined ordering rules. Thus, responses received from the split transaction bus may have to be reordered to comply with the ordering protocol of the general communication link.
Often, target devices are responsible for returning responses in a predefined order over a split transaction bus. These target devices typically require dedicated resources, such as circuitry and memory structures, to implement an ordering protocol. However, resources configured to implement an ordering scheme in a target device may limit the device's “read” bandwidth, i.e. how quickly data is retrieved from memory. For example, if a first-in, first-out (FIFO) queue in a target device maintains the order of requests received from a split transaction bus, then a delay processing a first request in the queue affects the processing times for subsequent requests in the queue. In those situations where requesting sources are configured to reorder responses received from a split transaction bus, each source must consume resources and bandwidth to implement the ordering protocol.